プロダクト開発チームの「開発テーマ」を考える

内製化支援コーチ 杉井です。

本記事ではプロダクト開発チームが掲げる「開発テーマ」について考えてみます。

ローンチからある程度の年月が経ち技術的負債が目立ち始めたプロダクトの開発・運用（DevOps）に携わる方々を想定しています。攻めと守りのバランスに日々悩むチームにとって参考になれば幸いです。

「開発テーマ」とは

本記事での「開発テーマ」は、プロダクトバックログやスプリントゴールよりも抽象度が高くプロダクトのマイルストーンやロードマップに描かれるようなものを想定しています。

例えば「データ分析基盤の強化」「会員管理機能の刷新」のような粒度のものです。

ロードマップやマイルストーンは主に社外に向けたプロダクトの説明であり、リファクタリングなどの開発内部のマイルストーンは記載しないことが多いでしょう。今回はその内部向けのものを「開発テーマ」として掘り下げてみます。

なぜ「開発テーマ」が必要なのか？

多くのプロダクト開発チームではアジャイル型の開発プロセスを採用し、開発するものの優先順位を決めながら進めて行くことが多いでしょう。

機能追加や機能改善など直接ユーザーの価値となるものは優先順位を考えやすいですが、一方でリファクタリングやドキュメント整備、テストの自動化などもプロダクトの運用をしていく中では重要なものです。

機能追加を優先するのかリファクタリングを優先するのかプロダクトオーナー（PO）やプロダクトマネージャー（PdM）がバランスをとるべき事ではありますが、システムを預かる開発チームとしてリファクタリングやドキュメント整備の重要性を説明する責任があります。

本記事であげていくようなテーマを年度のはじめに（または随時）PO/PdMと議論しておくと円滑に優先順位を決めることができます。

開発テーマの例

大きく、売上・利益（業績に係るもの）、中長期的なリファクタリング、ビジネス環境への適応、可視化、利用者体験の向上の5テーマに分けています。

売上・利益

プロダクトを運用している以上、業績の向上をテーマにするのは自然です。このテーマだと以下のような開発を行うことになります。

• 売上向上を狙った機能追加・機能変更
  • 製品のロードマップに沿った機能追加
  • BtoBの場合だと新規顧客との契約を狙ったアドホック的な機能追加
• 利益向上を狙った開発やタスク
  • サーバーコスト削減
    • サーバー構成を最適化するなど
  • 運用コストの削減
    • テストやリリース作業工数の削減（手順化や自動化など）
    • 監視・障害対応工数の削減を狙った改善
    • 問い合わせ対応の工数削減（マニュアル化・自動化など）

中長期的なリファクタリング

今は問題はないが2～3年後のビジネス成長を考えた時に進めておかなければいけない大規模なものというイメージです。

例えばDBの移行やシステム構成の変更などです。

アジャイル開発をやっているとこのような大規模になりそうなリファクタリングや構成変更は後回しになりがちですので取り組むべきテーマとしてあげておくことで着実に進めることができます。

ビジネス環境への適応

セキュリティ強化・プライバシー強化、レピュテーションリスク対応、法改正への対応など、ユーザー価値とはまた違った対応が必要となることがあります。こちらも開発規模が大きくなりがちなので長いスパンで考えておく必要があるテーマです。

可視化

プロダクトを続けていく中で可視化は欠かせません。計測できないものは改善できません。計測・可視化が十分ではないチームも多いと思いますのでテーマとして掲げることで取り組みやすくしましょう。

• サービスレベル（SLA/SLO）可視化の仕組み構築
  • MTTR、レイテンシなどサービスレベルの可視化を容易に見れるようにする
• 品質・デプロイ数の計測の仕組みを作る
  • DevOpsスコア = デプロイ数÷営業日÷人数
    • 開発からデプロイにボトルネックがなく効率よく・怖がらずにリリースができていることがわかる指標
    • 0.1前後だと健全だと言われています
    • 10人のチームだと、2週間（10営業日）で10個をデプロイする
    • 広木大地さん（@hiroki_daichi）が用いてる指標です。
  • 障害発生率 = 障害数÷デプロイ数
    • 障害は少ないに越したことはないですが、デプロイ数に基づいて算出することで適切な数字となります
    • 0.15程度が妥当と言われています
• 稼働割合を計測する仕組みを作る
  • どのような種類のタスクに稼働を使っているのかを計測することで改善に繋がります
  • ①前向きな稼働
    • 機能追加やテスト、リファクタリングなどプロダクトを良くするために使っている稼働時間
  • ②運用に必要な稼働
    • リリース作業、回帰試験、保守作業、問い合わせ対応など必要だが省略可すべき稼働時間
  • ③後ろ向きな稼働
    • 表現に困る種類の稼働ですが（笑）、障害対応の稼働、障害に関係する稼働（再発防止策のタスク）など、極小化したい稼働時間

利用者体験の向上

UX（User eXperience）の向上、APIなどの開発者向けだとDX（Developer eXperience/開発者体験）の向上も一つのテーマです。UXはPO/PdMの守備範囲ですがDXは開発チームが考えるほうが適切でしょう。DXだと以下のような例があります。

• API、SDKなどを導入・利用しやすい仕様にする
• 技術ドキュメントの改善
• サンプルコード、テンプレートの拡充

優先度を議論しよう

いくつかテーマをあげていきましたがこれらを思いつきで提案しても混乱するだけです。中長期的にプロダクト進化のアジリティを保つために今をどう過ごすのか。それぞれのテーマの優先順位、比重などをPO/PdMと開発チームで議論しましょう。

さいごに

開発チームが考えるべきテーマをいくつか紹介しました。参考にしていただき良いプロダクトの一助になれば幸いです。

より詳しく聞きたい、チーム作りを手伝ってほしいという方は以下からお問い合わせください。

内製化支援サービス | クラスメソッド